Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-111.txt

Text File | 1992-12-31 | 47.8 KB | 1,359 lines | [TEXT/R*ch]

C.S.M.P. Digest             Thu, 11 Jun 92       Volume 1 : Issue 111

Today's Topics:

    THINK C and basic AppleTalk comm ?
    MPSR resource
    Metrowerks PASCAL
    MacTCP
    mpw c++/cfront latest version?
    Opening windows with explosions ?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

Subject: THINK C and basic AppleTalk comm ?
From: [e-mail]
Date: 10 May 92 14:43:02 +0200
Organization: University of Geneva, Switzerland

Hi Mac Programmers !

I would like to know if there are some ready-to-use THINK C routines to
handle basic AppleTalk communications ?
I would like to be able to get each Mac name connected to my Mac (under Sys 7)
and send them the same message through AppleTalk (the way AppleShare does
when shutting down).

If such a package exists, where can I get it? Shareware, Freeware ?

Thanks for the help !

Sincerely,

Steve Jordi

+-------------------------+----------------------------------------------+
| Dpt of Geophysics       | Fax: + 41 22 320-5732                        |
| University of Geneva    |                                              |
| 13, Rue des Maraichers  | E-Mail: Internet:   [e-mail]      |
| 1211 GENEVA 4           |         Bitnet:     [e-mail]    |
| Switzerland             |         Compuserve: 70143,3056 (once a week) |
+-------------------------+----------------------------------------------+


---------------------------

From: [e-mail] (Kenneth Cheng-Lim Seah)
Subject: MPSR resource
Date: 30 Apr 1992 13:33:45 -0500
Organization: ESCware Associates


I've noticed that MPW and Think C use the MPSR resource (if I remember...
I don't have resedit handy now and I think that's the name of the resource) to
store the Marks placed in the text file.  if you have the format and can post
it, please do so... -- Thanks a zillion -- Ken
- --
Kenneth Seah ([e-mail]|PO Box 8565, Austin, TX 78713-8565|TAY 5.144)
Grad Student, Dept of Computer Sciences, University of Texas at Austin
"Money means nothing 'cause hacks are free..." (Apologies to MK)
Disclaimer:  Disclaim 'er?? Why I don't even know 'er...

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 May 92 00:47:16 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Kenneth
Cheng-Lim Seah) writes:
>
> I've noticed that MPW and Think C use the MPSR resource (if I remember...
> I don't have resedit handy now and I think that's the name of the resource) to
> store the Marks placed in the text file.  if you have the format and can post
> it, please do so...


#define resourceType    'MPSR'
#define editMarkID       1007

struct MarkElement {
    int             start;                  // start position of mark
    int             end;                    // end position
    unsigned char   charCount;              // number of chars in mark name
    char            name[1];                // first char of mark name
};                                          // (name is null terminated)


struct MarkRsrc {
    short count;                            // number of marks in the resource
    MarkElement mark[0];                    // zero or more mark elements
};

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Reid Ellis)
Date: 4 May 92 04:17:55 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Keith Rollin <[e-mail]> writes:
|
|#define resourceType    'MPSR'
|#define editMarkID       1007
|
|struct MarkElement {
|    int             start;                  // start position of mark
|    int             end;                    // end position
.. etc

Hey Keith, are those "int"s 32-bit or 16-bit?  :-)

Reid
- --
Reid Ellis
[e-mail]        ||           [e-mail]
[e-mail] ||  [phone] [work]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 7 May 92 23:20:07 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Reid Ellis) writes:
>
> Keith Rollin <[e-mail]> writes:
> |
> |#define resourceType    'MPSR'
> |#define editMarkID       1007
> |
> |struct MarkElement {
> |    int             start;                  // start position of mark
> |    int             end;                    // end position
> .. etc
>
> Hey Keith, are those "int"s 32-bit or 16-bit?  :-)

Depends. On older machines, they were 24-bit. Nowadays, you could ask Gestalt:

err = Gestalt(gestaltIntSize, &sizeOfInt);

This way, when Apple goes to 64-bit ints in System 8.0 (on the Richter scale),
you'll be prepared. Be sure not to miss the panel on this at the WWDC next week!

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.



+++++++++++++++++++++++++++

From: [e-mail]
Date: 7 May 92 17:32:06 GMT
Organization: unknown

In article <[e-mail]>
[e-mail] ([e-mail] (Reid Ellis)) writes:
>Keith Rollin <[e-mail]> writes:
>|
>|#define resourceType    'MPSR'
>|#define editMarkID       1007
>|
>|struct MarkElement {
>|    int             start;                  // start position of mark
>|    int             end;                    // end position
>.. etc
>
>Hey Keith, are those "int"s 32-bit or 16-bit?  :-)
>
>Reid
>--
>Reid Ellis
>[e-mail]        ||           [e-mail]
>[e-mail] ||  [phone] [work]

Execuse me please, I've missed the beginng of the discussion.
What are you talking about.

Thanx in advance.
Best,
Paul Kurzaev
Russia, Moscow University Computer Center
AppleLink: MOSCOW.UNIV
eMail:     [e-mail]

---------------------------

From: [e-mail] (Hartmut Semken)
Subject: Metrowerks PASCAL
Organization: netmbx, Berlin, Germany
Date: Thu, 30 Apr 1992 18:16:58 GMT


Hello out there.

Does anybody know Metrowerks PASCAL for the Mac?

>From the specs (runs on any Macintosh, Turbo Pascal compatible) it
sounded really nice; I bought it.

Sadly, it does not run on a Q700. Neither with nor without the cache.
With or without any Inits and Cdevs, all I get is a system bomb with
error code 11 (what does this mean anyway?).

In the documentation they give a net adress "[e-mail]".
Does anybody know this host? The european name server doesn't.

please help.
hase
- --
hase
Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37     [e-mail]
" I liked ZORK. I loved THE PAWN, but then I needed
  an adult adventure. I bought UNIX.

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Date: 1 May 92 01:10:31 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (Hartmut Semken) writes:
>
> Does anybody know Metrowerks PASCAL for the Mac?
>
> From the specs (runs on any Macintosh, Turbo Pascal compatible) it
> sounded really nice; I bought it.
>
> Sadly, it does not run on a Q700. Neither with nor without the cache.
> With or without any Inits and Cdevs, all I get is a system bomb with
> error code 11 (what does this mean anyway?).

Yeah I had similar problems.  I did an evaluation of Metrowerks Pascal
and found it to be sadly lacking.  Wich was a shame because neither
of the big two Mac Pascal's (Think and MPW) show any sign of
moving with the times.  They seem more interested in their C products
)-:

> In the documentation they give a net adress "[e-mail]".
> Does anybody know this host? The european name server doesn't.

My Metrowerks Modula 2 manual gives their address as
<[e-mail]> and I've definitely had success mailing to
that address.  You might try the postmaster there.

Share and Enjoy.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 1 May 92 02:54:26 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] (Quinn "The Eskimo!") writes:
>
>Yeah I had similar problems.  I did an evaluation of Metrowerks Pascal
>and found it to be sadly lacking.  Wich was a shame because neither
>of the big two Mac Pascal's (Think and MPW) show any sign of
>moving with the times.  They seem more interested in their C products
>)-:

    What sort of 'moving' did you have in mind? Both MPW and THINK
Pascal have kept up with the latest Toolbox, machine, and system software
revisions, and it's not like there have been any major changes to the
Pascal standard to be implemented. Both linkers support 'far' models
(MPW's does both far code and far data, THINK's does far code), which
is useful for writing large programs, particularly with class libraries.
Both environments include up-to-date class libraries, as well. (MPW's
is optional, THINK's is included at no cost.)

R.



- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer, Quickdraw Group
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Sun, 3 May 1992 05:22:25 GMT

In article <[e-mail]>, [e-mail] (Rich Siegel) writes:
>
> In article <[e-mail]> [e-mail] (Quinn "The Eskimo!") writes:

> >of the big two Mac Pascal's (Think and MPW) show any sign of
> >moving with the times.  They seem more interested in their C products
> >)-:
>
>     What sort of 'moving' did you have in mind? Both MPW and THINK
> Pascal have kept up with the latest Toolbox, machine, and system software
> revisions, and it's not like there have been any major changes to the
> Pascal standard to be implemented. Both linkers support 'far' models
> (MPW's does both far code and far data, THINK's does far code), which
> is useful for writing large programs, particularly with class libraries.
> Both environments include up-to-date class libraries, as well. (MPW's
> is optional, THINK's is included at no cost.)

How bout fixing the editor bugs that have been around since THINK Pascal
version 3 (such as the wayward outlining leaving trails, or the really
fun disappearing begin's).  How bout larger that 64k structures and more
that 64k globals.  How bout structured constants such as those available
in Turbo Pascal since god knows when (1986?).  How bout warnings on
dangerous use of object fields (such as passing to var parameters).  How
bout multiple errors detected per compile.  How bout warnings for unsued
variables, or functions with no return value.  Perhaps some language
extensions such as exceptions.  Perhaps nested comments would be nice,
and multiline comments as well.  An option for relaxed string range checking
would be nice.  Range Checking code that did sensible things in compiled
apps (instead of bombing on machines without macsbug and doing nothing
on machines with macsbug - great for debugging)-: would be good.

Well, that should do for starters.  Basically you are quite right, THINK
and MPW pascals have kept up to date with the system libraries, but
aside from that and far code there have been almost no improvements in
years.

I like and use TP, but I am getting the impression that neither Apple
nor Symantec are very interested in doing anything with their pascal
compilers - Please Prove Me Wrong!

Have fun all,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]



+++++++++++++++++++++++++++

Organization: Johannes Kepler University Linz - Computing Center
Date: Sunday, 3 May 1992 15:30:07 CDT
From: Norbert Mueller <[e-mail]>

My worst complaint about Pascal being neglected in favor of C is that
Think C 5.0 has far better optimization than Think Pascal 4.0.

N. Mueller

P.S.: A Turbo Pascal compatible compiler for the Mac would facilitate
porting a lot (but who ports? everybody writes everything from scratch in oop,
dont we :-)

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Date: 5 May 92 01:50:14 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (Norbert Mueller) writes:
>
> My worst complaint about Pascal being neglected in favor of C is that
> Think C 5.0 has far better optimization than Think Pascal 4.0.

Damn the optimisations!  If I wanted speed I'd write it in assembler.  Which
leads to my complaint about both Pascal compilers which is that neither
have an inline assembler.  Think C has had one for ever (as far as I can
tell) (I've don't, and never have, used C, Think or otherwise).  At least
with MPW you can use Asm but when writing in Think Pascal you're stuffed
Can anyone say hex boys and girls?  I thought hand assembly went out with
valves!

> P.S.: A Turbo Pascal compatible compiler for the Mac would facilitate
> porting a lot

Porting PC programs (ie those written in Turbo) strikes me as difficult.  What
does one do with all those character graphics?  That's one of the things
that I couldn't understand about Metrowerks.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who, despite his raving compaints, still uses Pascal.

+++++++++++++++++++++++++++

From: [e-mail] (David Lee Matuszek)
Organization: Paoli Research Center - Paoli, PA
Date: Wed, 6 May 1992 19:49:19 GMT

In article <[e-mail]> [e-mail] (Quinn "The Eskimo!") writes:
>
>Damn the optimisations!  If I wanted speed I'd write it in assembler.  Which
>leads to my complaint about both Pascal compilers which is that neither
>have an inline assembler.  Think C has had one for ever (as far as I can
>tell) (I've don't, and never have, used C, Think or otherwise).  At least
>with MPW you can use Asm but when writing in Think Pascal you're stuffed
>Can anyone say hex boys and girls?  I thought hand assembly went out with
>valves!

RIGHT ON!!!!!!!!!!!!!!!!!!!!!!!!

>Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
>Department of Computer Science, The University of Western Australia
>  -- Who, despite his raving compaints, still uses Pascal.

Likewise.




- --

- -- Red meat isn't bad for you.  Fuzzy blue-green meat is bad for you.   --
- -- Dave Matuszek ([e-mail])  I don't speak for my employer.  --
t3

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 May 92 01:19:52 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Quinn "The Eskimo!") writes:

> In article <[e-mail]>, [e-mail]
(Norbert Mueller) writes:

> > My worst complaint about Pascal being neglected in favor of C is that
> > Think C 5.0 has far better optimization than Think Pascal 4.0.

> Damn the optimisations!  If I wanted speed I'd write it in assembler.  Which
> leads to my complaint about both Pascal compilers which is that neither
> have an inline assembler.  Think C has had one for ever (as far as I can
> tell) (I've don't, and never have, used C, Think or otherwise).  At least
> with MPW you can use Asm but when writing in Think Pascal you're stuffed
> Can anyone say hex boys and girls?  I thought hand assembly went out with
> valves!

C and Pascal and C++ and LISP and... Gee, language wars are so constructive.
Anyway, the problem with asm use in future are those RISC boxes we will start
producing. I don't state that it will be impossible to convert asm code
from 68k to PowerPC. However it's another element of surprise project leaders
get ulcer from.

That's the reason I'm for compilers that produce highly optimized code. It
certainly does not hurt.

Cheers,
Kent

+++++++++++++++++++++++++++

Organization: Johannes Kepler University Linz - Computing Center
Date: Thursday, 7 May 1992 14:56:19 CDT
From: Norbert Mueller <[e-mail]>

I still do believe optimizing compilers are important! Complex simulation
programs of some 10000 lines math intensive code simply cannot be hand-
optimized in assembly. My experience shows that although hand-assembly
is undoubtedly faster in execution, the additional time needed for debugging
rarely is worth the effort.
Also computers excel in facilitating repeated tasks. So I prefer my
computer to optimize the nth incarnation of <your favorite source code here>.

Just my opinion.

N. Mueller

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Mon, 11 May 1992 06:01:51 GMT

In article <[e-mail]>, Norbert Mueller <[e-mail]> writes:
>
> I still do believe optimizing compilers are important!

> My experience shows that although hand-assembly is undoubtedly faster in
> execution, the additional time needed for debugging
> rarely is worth the effort.

> Also computers excel in facilitating repeated tasks. So I prefer my
> computer to optimize the nth incarnation of <your favorite source code here>.

All very valid points.  This topic started with my "Damn the optimisations"
comment which was misinterpreted as meaning I prefer to do my optimisations
in assembler.  Not really true.  I much prefer the compiler to do the
optimisations however there are some things that I need to do in
assembly eg clikLoop procedures for TextEdit.  So although optimisations
are nice, a good assembler is *necessary*.  And the best assemblers
are integrated into the programming environment.

Now if Apple sorted out their interfaces this problem would go away (-:

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia


---------------------------

From: [e-mail] (Francois Schiettecatte)
Subject: MacTCP
Organization: Johns Hopkins Univ. Welch Medical Library
Date: Tue, 14 Apr 1992 13:25:07 GMT

Hi

I have a quick question about MacTCP and DNR. When the  drivers are
opened do they get loaded into the application's memory space. I am
asking this because I am writting a small application which uses
them and when I open up the MacTCp driver a chunk of my applications
memory gets allocated, same goes for DNR. I am assuming that this is
due to the drivers getting loaded. The problem with that is that the
space gets allocated as pointers and cannot move, is there a way I
can cause the drivers to get loaded when I start my application up
with just a couple of function calls so that the space allocated is
as low in memory as possible.



Francois Schiettecatte
Internet: [e-mail]
Phone    : [phone]


+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 15 Apr 92 16:00:14 GMT
Organization: University of Illinois at Urbana-Champaign

>>> Why not just use BlockMove?
>>Even something as trivially simple as:
>>    while (n--) *(q++) = *(p++);
>>is faster than BlockMove for n < 50 - even as a subroutine!
>Yes. A friend did a study of this and came up with a break-even point of about
>32 to 34 bytes for a byte-copy loop, about 50 bytes for an unrolled byte-copy
>loop.

It's pointless and counterproductive to worry about the time you save using
custom assembly (or C) instead of BlockMove, unless you are in an inner loop of
a time-critical section of code.  The few cpu cycles you save are no
more valuable than the few bytes of memory you lose by not using the trap.
AND you have to worry about compatibility (the original question was regarding
the safety of using MOVE.W on some address returned by something or other).

Unless it's in a critical inner loop, forget it, and concentrate on something
that will do some good.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (John Purlia)
Organization: Qualcomm Incorporated
Date: Thu, 23 Apr 1992 20:51:49 GMT

Can anyone provide a little insight as to what "network failure" indicates
in MacTCP?  Periodically, my asynchronous calls to TCPSend return a result
code of -23012, connectionTerminated.  I installed an asynchronous
notification routine to further identify the problem and in the terminReason
I find "network failure" as oppose to other codes which would indicate an
explicit close of the TCP connection.

So what does it mean?  Did the net take a temporary hit?  After clearing the
alert which reports the TCPSend error, things seem to fun okay.

Thanks!

..........................................................................
John Purlia          : My brain; not my company's brain.  My brain says...
[e-mail] :      "Just about any movie could be made better
AOL:  <Jpurlia>      :       if one of the characters were a vampire."
..........................................................................


+++++++++++++++++++++++++++

From: [e-mail] (Boyd Hays)
Organization: Colorado SuperNet, Inc.
Date: Sat, 2 May 1992 17:13:12 GMT

Hello,

    Has anyone ported SUN's RPCSRC or TIRPC to the Macintosh for use with
    either ADSP or MacTCP? There was a reference in John Bloomer's RPC book
    that it had been ported to the Mac, but I didn't see where one could
    obtain it.

    Is it possible to use the Mac TCP to communicate with another process
    on the same Macintosh? Efectively, I'd like to develop an application
    locally and then migrate the parts.

    I'm looking for a BSD compatible socket library that uses MacTCP. I've
    found one in isode for the Mac, but it didn't work "out of the box" and
    I haven't investigated the problem. I've also tried the one done by
    Tom Milligan and subsequently modified by Adrian Wong and David Kovar
    for ThinkC but a file "MPWGlobals.h" seems to be missing. Does anyone
    know where the latest and greatest version of a ThinkC version of this
    work might be found?

Thanks in advance,
Boyd Hays
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Johnny N.)
Date: 7 May 92 19:36:18 GMT
Organization: Purdue University Engineering Computer Network

Dear netters,

  I am trying to write a simple interface between and Mac and a UNIX
  box, where the UNIX box sits and waits for requests, and then
  sends some data back to the Mac.  I would like to just use
  some simple socket protocol.
  Is there a package that implements sockets on top of the MacTCP?
  And where can I get it?

  Or is there a better way to do this that I am missing?


Thanks,

- -John

+++++++++++++++++++++++++++

From: [e-mail] (Bertrand Limoges)
Organization: Sobeco Ernst & Young
Date: Fri, 8 May 1992 21:31:30 GMT

Hi,

I've obtained the MacTCP 1.1 Examples from ftp.apple.com and have modified the
MPW MPing sources to compile under THINK C 5.0. However, when I compile and run
it, I get the 'Cannot open Resolver' alert and the application does an
ExitToShell. I've checked the resolver.c source, a slight modification of the
dnr.c supplied with the MacTCP developer's kit. The code does get hold of the
dnrp resource, but when the rc = (*dnr)(OPENRESOLVER, fileName) line is
executed, I get an rc of -1. nil is being passed as fileName, which according
to the MacTCP Programmer's Guide is OK.

Anyone out there has any idea on what's going on? Alternately, pointers to
other example sources for MacTCP would be appreciated.

Much obliged, Bertrand Limoges, Sobeco Ernst & Young, Montreal, Canada


+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Sat, 9 May 1992 16:40:51 GMT

[e-mail] (Bertrand Limoges) writes:

>I've obtained the MacTCP 1.1 Examples from ftp.apple.com and have modified the
>MPW MPing sources to compile under THINK C 5.0. However, when I compile and run
>it, I get the 'Cannot open Resolver' alert and the application does an
>ExitToShell. I've checked the resolver.c source, a slight modification of the
>dnr.c supplied with the MacTCP developer's kit. The code does get hold of the
>dnrp resource, but when the rc = (*dnr)(OPENRESOLVER, fileName) line is
>executed, I get an rc of -1. nil is being passed as fileName, which according
>to the MacTCP Programmer's Guide is OK.

>Anyone out there has any idea on what's going on? Alternately, pointers to
>other example sources for MacTCP would be appreciated.

Yup. You see those declarations at the top of dnr.c which say things
like "#define OPENRESOLVER 1"? Change them to all to have an "L" after
the number, like:

#define OPENRESOLVER 1L

That way they will be longs instead of ints.

Also make sure that anything declared "int" in the header files is
changed to a "long" for THINK C (unless you have ints as longs checked
in your Options).

It is just silly that the dnr code does not do these things already.

(*Sigh*)

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

From: [e-mail] (Steve Krans)
Subject: mpw c++/cfront latest version?
Date: 19 Apr 92 22:05:27 GMT
Organization: People-Net [pnet51], Minneapolis, MN.

What is the latest version of cfront that apples has ported?

Steve

UUCP: {tcnet, crash, quest}!orbit!pnet51!skrans
ARPA: crash!orbit!pnet51![e-mail]
INET: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Mon, 20 Apr 1992 01:54:49 GMT

[e-mail] (Steve Krans) writes:

>What is the latest version of cfront that apples has ported?

I think it's MPW CPlus/CFront 3.2 final, based on AT&T 2.1.1.
- --
Mark Lanett, Software Tools Group, NCSA; [e-mail]; NCSA.STG (AppleLink)

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 21 Apr 92 19:03:27 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Mark Lanett) writes:
> [e-mail] (Steve Krans) writes:
> >What is the latest version of cfront that apples has ported?
> I think it's MPW CPlus/CFront 3.2 final, based on AT&T 2.1.1.

AT&T has funny release levels, I think we ended up with AT&& 2.1.14
with Apple bug fixes added to the source code. It's on ETO#7.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 30 Apr 92 03:56:34 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail]
>(Mark Lanett) writes:
>> [e-mail] (Steve Krans) writes:
>> >What is the latest version of cfront that apples has ported?
>> I think it's MPW CPlus/CFront 3.2 final, based on AT&T 2.1.1.
>
>AT&T has funny release levels, I think we ended up with AT&& 2.1.14
>with Apple bug fixes added to the source code. It's on ETO#7.

So when are we going to catch up with the rest of the world?  I could
really use templates...

+C, anxiously waiting for CFront 3.0.  For that matter, also awaiting
a real C++ compiler!


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Sun, 3 May 1992 23:23:10 GMT

[e-mail] (Cory Kempf) writes:

>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik) writes:
>>In article <[e-mail]>, [e-mail]
>>(Mark Lanett) writes:
>>> [e-mail] (Steve Krans) writes:
>>> >What is the latest version of cfront that apples has ported?
>>> I think it's MPW CPlus/CFront 3.2 final, based on AT&T 2.1.1.
>>
>>AT&T has funny release levels, I think we ended up with AT&& 2.1.14
>>with Apple bug fixes added to the source code. It's on ETO#7.

>So when are we going to catch up with the rest of the world?  I could
>really use templates...

What was it I heard an Apple person say? "We're taking a look-and-see attitude".
In March they hadn't decided whether to roll their own or go with 3 (actually,
they already *had* 3 but hadn't done the full MPW port yet).

There's at least one company in the unix world selling a 3-oh proprocessor;
don't know what it would take to work on the Mac, or if it would like
HandleObjects. There's also "genclass" from g++ and a pd template preprocessor
that apparently is pretty close to 3... And macros, of course (my solution,
for various reasons).

>+C, anxiously waiting for CFront 3.0.  For that matter, also awaiting
>a real C++ compiler!

Anyone tried out rev2 of ZC++ yet?

Doesn't BC++ have telmplates *and* exceptions now?
- --
Mark Lanett, NCSA Software Development                         [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 4 May 92 22:02:55 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Cory
Kempf) writes:
>
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail]
(Kent Sandvik) writes:
> >In article <[e-mail]>,
[e-mail]
> >(Mark Lanett) writes:
> >> [e-mail] (Steve Krans) writes:
> >> >What is the latest version of cfront that apples has ported?
> >> I think it's MPW CPlus/CFront 3.2 final, based on AT&T 2.1.1.
> >
> >AT&T has funny release levels, I think we ended up with AT&& 2.1.14
> >with Apple bug fixes added to the source code. It's on ETO#7.
>
> So when are we going to catch up with the rest of the world?  I could
> really use templates...

The rest of the world is also catching up on templates, there are
few C++ compilers today that supports this feature. Another reason
it takes some time to implement them has to do with the #@$%(T#$%
way AT&T wrote in template support into the compiler, it's rather gross
and I think we rest would like to implement something more support
friendly.

> +C, anxiously waiting for CFront 3.0.  For that matter, also awaiting
> a real C++ compiler!

Aren't we all, I gave up and am personally spending most of my private
hacking time on dynamic languages :-).

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Thu, 7 May 92 21:58:21 EST
Organization: EnigamI, Inc., Nashua, NH


In article <mlanett.704935390@void> (comp.sys.mac.programmer), [e-mail] (Mark Lanett) writes:
>[e-mail] (Cory Kempf) writes:
>>+C, anxiously waiting for CFront 3.0.  For that matter, also awaiting
>>a real C++ compiler!

>Doesn't BC++ have telmplates *and* exceptions now?

>From everthing that I have heard, BC++ is a full implimentation of
the 3.0 language definition.

The availability of tools is one of the few things that make me consider
switching over to Windows / OS/2 (Still short lived flights of fancy
/ nightmares).

It is also one of the arguements that I cannot counter when I try
to convince people to look at the Mac.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Thu, 7 May 92 22:05:01 EST
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>, [e-mail] (Cory
>Kempf) writes:
>> So when are we going to catch up with the rest of the world?  I could
>> really use templates...
>
>The rest of the world is also catching up on templates, there are
>few C++ compilers today that supports this feature. Another reason
>it takes some time to implement them has to do with the #@$%(T#$%
>way AT&T wrote in template support into the compiler, it's rather gross
>and I think we rest would like to implement something more support
>friendly.

I would have thought that Apple would have learned their lession after
the Green Hills Debicle -- Apple cannot afford to farm out something
as mission critical as compilers.  Not to Green Hills, nor to AT&T.

>> +C, anxiously waiting for CFront 3.0.  For that matter, also awaiting
>> a real C++ compiler!

>Aren't we all, I gave up and am personally spending most of my private
>hacking time on dynamic languages :-).

Nice, but unfortunately, the rest of us don't have that luxury.  We
need to be able to build small, fast, maintainable code.  From what
I have seen of dynamic languages, while they are fun to play in, and
while they do have their nitch, they are not suited to production code.
Do you know something I don't?

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Fri, 08 May 92 12:51:49 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] writes:
>
>I would have thought that Apple would have learned their lession after
>the Green Hills Debicle -- Apple cannot afford to farm out something
>as mission critical as compilers.  Not to Green Hills, nor to AT&T.

Hey, I LIKED MPW C 2.0.2



- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Fri, 8 May 92 14:25:10 GMT

In article <[e-mail]> [e-mail] writes:
>
>In article <mlanett.704935390@void> (comp.sys.mac.programmer), [e-mail] (Mark Lanett) writes:
>>[e-mail] (Cory Kempf) writes:
>>>+C, anxiously waiting for CFront 3.0.  For that matter, also awaiting
>>>a real C++ compiler!
>
>>Doesn't BC++ have telmplates *and* exceptions now?
>
>From everthing that I have heard, BC++ is a full implimentation of
>the 3.0 language definition.
>

No, Borland C++ 3.0 does not have exceptions-handling. (Or, if it does,
it is entirely undocumented). MSC/C++ 7.0 does (but I don't think it does
anything with templates yet, which Borland does).

It's aggravating - I'm looking at both packages, trying to determine which
to use for a project. Borland C++ has a class library for developing character-
based DOS apps with a simple GUI. Microsoft has excellent foundation classes
for data structures that are very well-documented, but no DOS-based GUI
classes. The Borland documentation seems to be pretty inadequate. I'd like
to be able to take the container classes from Microsoft and the GUI classes
from Borland, but I suspect that way would lie flaming death...

- --
"breakpoints" _See_also_ debugging, watch expressions; "debugging breakpoints"
 _See_ breakpoints; "debugging watch expressions" _See_ watch expressions;
"watch expressions" _See_also_ debugging... (Borland C++ manual index)
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 8 May 92 16:38:22 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.umd.edu> [e-mail] (Matthew T. Russotto) writes:

   >the Green Hills Debicle -- Apple cannot afford to farm out something
   >as mission critical as compilers.  Not to Green Hills, nor to AT&T.

   Hey, I LIKED MPW C 2.0.2

I'm only sorry they didn't choose DCC. But that may be from a
slightly biased viewpoint...

- --
h++ - new and improved !

"It's simple. Some people have braces in their names, and some don't. You'll
   just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Organization: Visix Software Inc., Reston, VA
Date: Sun, 10 May 92 05:26:53 GMT

[e-mail] (Matthew T. Russotto) writes:
> Hey, I LIKED MPW C 2.0.2

Me too.  At least it handled complex expressions correctly, which is more
than you can say for the first several versions of MPW C 3.x.  I still have
code that MPW C 2.0.2 compiled correctly that MPW C blows up on.

Now, don't get me wrong--the latest versions of MPW C are nice and spiffy,
and have some great improvements over 2.0.2.  On the other hand, it's only
now even approaching the stability of the old Green Hills compiler...


Amanda Walker                        [e-mail]
Visix Software Inc.                     [phone]
- --
"It can hardly be coincidence that no language on earth has ever
 produced the expression "As pretty as an airport."    --Douglas Adams

---------------------------

From: [e-mail]
Subject: Opening windows with explosions ?
Date: 24 Apr 92 15:11:07 GMT
Organization: University of Geneva, Switzerland

Hi there,
When opening and displaying a new window on the Mac screen... Is it possible
to opend it the way desktop folders do ? With explosion effects ?
I use Think C 5. Is there some examples somewhere ?

Thanks for any help !

Sincerely,

Steve Jordi

+-------------------------+----------------------------------------------+
| Dpt of Geophysics       | Fax: + 41 22 205-732                         |
| University of Geneva    |                                              |
| 13, Rue des Maraichers  | E-Mail: Internet:   [e-mail]      |
| 1211 GENEVA 4           |         Bitnet:     [e-mail]    |
| Switzerland             |         Compuserve: 70143,3056 (once a week) |
+-------------------------+----------------------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 1 May 92 19:50:27 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] writes:
>
> Hi there,
> When opening and displaying a new window on the Mac screen... Is it possible
> to opend it the way desktop folders do ? With explosion effects ?

They are called zoom rects and all you have to do it draw them with FrameRect.
It's almost trivial.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 1 May 92 19:50:52 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] writes:
>
> Hi there,
> When opening and displaying a new window on the Mac screen... Is it possible
> to opend it the way desktop folders do ? With explosion effects ?

They are called zoom rects and all you have to do it draw them with FrameRect.
It's almost trivial.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Ed Watkeys)
Date: Mon, 4 May 92 21:37:48 EDT
Organization: Distant Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jon Pugh) writes:
> In article <[e-mail]>, [e-mail] writes:
> >
> > Hi there,
> > When opening and displaying a new window on the Mac screen... Is it possible
> > to opend it the way desktop folders do ? With explosion effects ?
>
> They are called zoom rects and all you have to do it draw them with FrameRect.
> It's almost trivial.
>
> Jon
>

Frontier and associated programs bundled with it have a really nifty zooming
action, and the code can be found in the UserLand Frontier SDK, which can
be found on some FTP sites somewhere...

Ed

- --
Ed Watkeys (Drexel U. Comp Sci)  "Moral judgement and condemnation is
[e-mail]              the favorite form of revenge for the
[e-mail]      spiritually limited on those who are
ls.com!phlpa!caligula!edw         less so...." -- Friedrich Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (Juha Pirttil{)
Date: 5 May 92 10:19:06 GMT
Organization: Department of Physics, University of Oulu

Here is a Pascal procedure that will do the zoomRects effect between two
given rectangles on the current grafPort. It may
not be the most elegant solution (it has been written in a hurry) but
anyway it woks...

 procedure ZoomRects (alkuRect, LoppuRect: rect);
  var
   piirtoRect: array[1..8] of rect;
   dh, dv, offsetDh, offsetDv, i: integer;
   tickit: longint;

 begin
  piirtoRect[1] := alkuRect;
  PenMode(patXor);
  penPat(gray);
  dv := -((loppuRect.bottom - loppuRect.top) -
         (alkuRect.bottom - alkuRect.top)) div 16;
  dh := -((loppuRect.right - loppuRect.left) -
         (alkuRect.right - alkuRect.left)) div 16;
  offsetDh := (((loppuRect.right - loppuRect.left) div 2 +
loppuRect.left) -
      ((alkuRect.right - alkuRect.left) div 2 + alkuRect.left)) div 8;
  offsetDv := (((loppuRect.bottom - loppuRect.top) div 2 + loppuRect.top)
- -
      ((alkuRect.bottom - alkuRect.top) div 2 + alkuRect.top)) div 8;
  for i := 2 to 14 do
   begin
    if i > 6 then
     frameRect(piirtoRect[i - 6]);
    if i <= 8 then
     begin
      piirtoRect[i] := piirtoRect[i - 1];
      insetRect(piirtoRect[i], dh, dv);
      offsetRect(piirtoRect[i], offsetDh, offsetDv);
      frameRect(piirtoRect[i]);
     end;
    tickit := tickCount;  {to make the effect slow enough, looks }
    repeat                {better}
    until tickCount > tickit + 1;
   end;
  PenNormal;
 end;

Some comments: alkuRect is the starting rect and loppuRect is the
ending rect. dh & dv are the rect size offsets and offsetDh & offsetDv
are the location offsets of the rectangle.
PiirtoRect is an array of rectangles that is used to do the
actual zoom effect.

              Juha Pirttil{
              Department of Physics
              University of Oulu
              Finland

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 May 92 19:42:37 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Juha
Pirttil{) writes:
> Some comments: alkuRect is the starting rect and loppuRect is the
> ending rect. dh & dv are the rect size offsets and offsetDh & offsetDv
> are the location offsets of the rectangle.
> PiirtoRect is an array of rectangles that is used to do the
> actual zoom effect.

alku = beginning
loppu = end
Piirto = a verb-noun, eh, like the act or drawing.
It seems I still remember a little bit Finnish...


Here's some other code I found in my huge archive, not personally tested:

- ----
Here's how I did it in Pascal.  I haven't looked at this code for years,
but I use it frequently:

unit Zoom;

interface

{ZoomRect is a procedure which zooms a series of dotted rectangles from}
{startRect to endRect.  Pass it the rects in GLOBAL coordinates.}

procedure ZoomRect (startRect, EndRect: rect);

implementation

{-----------------------------------------------------------------------}
  procedure ZoomRect (startRect, EndRect: rect);
    const
      NumRects = 4; {Number of rectangles displayed at once (the latency)}
      Steps = 18;   {Coarseness of the grain}
    var
      TopStep, LeftStep, BottomStep, RightStep, i, j: integer;
      EmptyRect: rect;
      RectList: array[1..NumRects] of rect;
      aPort, oldPort: Grafptr;
      portStorage: GrafPort;
  begin
    TopStep := (EndRect.top - StartRect.top) div steps;
    LeftStep := (EndRect.left - StartRect.left) div steps;
    BottomStep := (EndRect.bottom - StartRect.bottom) div steps;
    RightStep := (EndRect.right - StartRect.right) div steps;

    GetPort(oldPort); {save the current port}

    aPort := GrafPtr(@portStorage); {make aPort point to stack storage}

{open the port and make it current -- whole screen is used}
    OpenPort(aPort);
    PenMode(notpatXor);
    PenPat(gray);

    SetRect(EmptyRect, 0, 0, 0, 0);
    for i := 1 to NumRects do
      RectList[i] := EmptyRect;

    for i := 1 to steps - 1 do
      begin
        FrameRect(RectList[1]);   {erase first rect}
        StartRect.top := StartRect.top + TopStep;
        StartRect.left := StartRect.left + LeftStep;
        StartRect.bottom := StartRect.bottom + BottomStep;
        StartRect.right := StartRect.right + RightStep;
        FrameRect(StartRect);   {paint next rect}
        for j := 1 to NumRects - 1 do
          RectList[j] := RectList[j + 1];
        RectList[NumRects] := StartRect;  {remember last rect}
      end;

    for i := 1 to NumRects do
      FrameRect(RectList[i]);     {final erasure}

    ClosePort(aPort); {close the temporary port}

    SetPort(oldPort); {restore the previous port}
  end;
end.

===============================================================================
Lincoln D. Stein                                Brigham & Women's Hospital
[e-mail]                           Boston, MA

- -----
Cheers, Kent
- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are not private, and not owned by any company, organization
or group. Happy happy, joy joy!

+++++++++++++++++++++++++++

From: [e-mail] (The Apathist)
Date: 9 May 92 22:37:44 GMT
Organization: Authorized Service, Incorporated

I know of two improvements that can be made to the ZoomRect algorithms
posted here:

First, to reduce flicker, erase the old rectangle and draw the new one
in a single step.  This can be acheived by putting the frame of each
rectangle into a region, calculating their exclusive or, and drawing
the result.  This is particularly beneficial when one side of the
rectangle may be moving very slowly.

Second, for a more pleasing effect, don't space the rectangles evenly.
Instead, have them bunch up towards the ends of the motion -- I
suggest using sine on [-pi,pi] to guide the motion.  The result is
that the rectangles start slowly, speed up, and slow to a halt at
their destination in a smooth motion.

                    --Tom Lippincott
                      [e-mail]

    "No problem is insoluble given a big enough plastic bag."
                    --Tom Stoppard, "Jumpers"

---------------------------

End of C.S.M.P. Digest
**********************